This invention pertains to the arts of computer networks, addressing of computers on computer networks, and the administration and management of the addressing schemes. In particular, this invention relates to the arts of Internet Domain Name Servers; creation of Universal Resource Locators, Domain and Subdomain names; and management of virtual subdomains.
This invention was not developed in conjunction with any Federally-sponsored contract.
A microfiche appendix consisting of 70 (seventy) frames on 1 (one) microfiche is submitted herewith, and its content is incorporated in its entirety into this specification.
The Internet is possibly the greatest advance in information technology since the invention of the Gutenberg movable type printing press. It""s impact on society worldwide has truly only been realized to a fraction of its ultimate potential. The Internet is not a single computer network, however, but is a hierarchy of many computer networks, all of which are interconnected by various types of server computers.
Key to success of the Internet is the addressing scheme which was adopted. The addressing scheme allows two types of addressing to be used when one computer transmits data to another computer over the Internet. The first addressing scheme, referred to as the Internet Protocol (xe2x80x9cIPxe2x80x9d) address, is a numeric address value consisting of four binary octets separated by a period or xe2x80x9cdotxe2x80x9d, such as AA.BB.CC.DD. Each of the octets is allowed to range in value from 0 to FF hexadecimal, or to 255 decimal. The values towards the left of the address, such as AA and BB, are referred to as network addresses and are used for coarse resolution of the address, while the values towards the right of the address are used for fine resolution of the address, such as CC and DD.
For example, turning to FIG. 1, the Internet backbone (1) is a set of high-speed data transmission facilities which interconnect several key switching and routing centers. Domain servers (2 and 6) may connect directly to the backbone (1), or they may connect indirectly to the backbone through other servers and other networks. For example, the domain server (2) on the right serves the subnetwork (4) on the right, which interconnects one or more client computers (5) to each other and to the Internet. Data or messages to be sent to any of the computers on the right-side network (4) must be properly addressed to be routed to them. For example, the right domain server (2) may be assigned a particular range or set of ranges of IP addresses to serve, such as 155.179.00.XX. A computer on the right-side network (4) may be given an address within this range, such as 155.179.00.213 (in decimal). A second computer on the right-side network (4) may be given an address such as 155.179.00.111. So, the octets towards the right of the IP address are subaddresses of the server""s address. This scheme of addressing and subaddressing is well known within the art.
This subaddressing scheme is designed to allow subnetworking as well. For example, as shown in FIG. 1, the left-side domain server (6) may be assigned an IP address range of 98.99.YY.XX (in decimal). Computers directly connected to its subnetwork (8) would receive addresses within this range, as given in the previous example. However, another subnetwork (11), or sub-subnetwork to be literally correct, may be interconnected to the left-side network (8) via another domain server, which may be referred to as a subdomain server (9). This subdomain server may be given a range of IP addresses within the range of IP addresses for the left-side network domain server (6), such as 98.99.192.XX. The internetworking scheme of the Internet is built upon this hierarchical structure of networks and addresses.
The use of the term xe2x80x9cdomainxe2x80x9d with respect to addressing actually implies more than the numeric IP addressing just discussed, in Internet parlance. While computers may deal well with numeric values for addressing, human users do not deal well with long numbers. When the architects of the early versions of the Internet, known as the ARPAnet, considered previous numbering schemes for humans, such as telephone numbers, they recognized this problem. In order to make the Internet more xe2x80x9cuser-friendlyxe2x80x9d, a text-based addressing scheme was xe2x80x9coverlaidxe2x80x9d on top of the numeric IP addressing scheme. Thus, a hierarchy of text-based addresses was defined. At the top of the hierarchy is a domain, which in general a large range of IP addresses or group of addresses. For example, in FIG. 1, the right-side domain server (2) may be assigned an easy to remember domain name such as xe2x80x9cuspto.govxe2x80x9d. Under the Internet domain name convention, the extension of the name following the period or xe2x80x9cdotxe2x80x9d helps to categorize the type of domain. In this example, xe2x80x9cgovxe2x80x9d refers to government domains. Coupled with the domain name, xe2x80x9cusptoxe2x80x9d, a particular domain server is addressed. Other extensions, such as xe2x80x9ccomxe2x80x9d for commercial uses, xe2x80x9ceduxe2x80x9d for educational institutions and xe2x80x9cnetxe2x80x9d for network services companies, are also available.
In order for messages and data to be actually routed to a computer using a domain name, a translation to a numeric IP address must be made. This is done by a number of distributed xe2x80x9cdomain name serversxe2x80x9d (xe2x80x9cDNSxe2x80x9d), which can be queried by Internet routers to provide the translation. Each domain server maintains records regarding IP-to-domain name assignments for the domains which it serves. This translation technique and the protocol for updating records is described in the Internet Request For Comment (xe2x80x9cRFCxe2x80x9d) papers, which are public documents available from InterNIC. Of particular interest are:
(a) RFC1033, Domain Administrators Operations Guide
(b) RFC1034, Domain Namesxe2x80x94Concepts and Facilities, and
(c) RFC1035, Domain Namexe2x80x94Implementation and Specification.
These are public documents, and are well known within the art.
Continuing with the analogical structure to numeric IP addressing, domain names may be broken into two types of more resolute addresses. The first type is based upon directory structure of the file system on the server. For example, a subdirectory on the US Patent and Trademark Office""s web server which contains general information might be named xe2x80x9cgen infoxe2x80x9d, and could be addressed as xe2x80x9cwww.uspto.gov/gen_infoxe2x80x9d. Subnetworks and virtual subnetworks may be addressed by prefixing the general domain name with a subdomain name or names. For example, a subnetwork which serves only the trademark division of the US Patent and Trademark Office may be given the subdomain name xe2x80x9ctmxe2x80x9d, allowing the subdomain server (such as 9 in FIG. 1) to be addressed as xe2x80x9ctm.uspto.govxe2x80x9d. The two addressing schemes can be combined, such as xe2x80x9ctm.uspto.gov/gen_infoxe2x80x9d, which would access a file named xe2x80x9cgen_info.htmlxe2x80x9d located in the root directory of the subdomain server for xe2x80x9ctmxe2x80x9d under the domain server for xe2x80x9cuspto.govxe2x80x9d. Alternatively, if a subdirectory called xe2x80x9cgen_infoxe2x80x9d exists on the subdomain server xe2x80x9ctmxe2x80x9d, a file named xe2x80x9cindex.htmlxe2x80x9d may be accessed by a web browser which is pointed to this fill address.
Virtual subdomains are special cases of subdomains, which may or may not actually refer to a separate subdomain server from the domain server, but may refer to a directory or other software facility on the domain server. This is referred to as xe2x80x9chostingxe2x80x9d the subdomain on the domain server. Later, if the owner of the subdomain desires, a separate subnetwork may be established with a separate subdomain server, and the routing tables on the domain server are updated to reflect a xe2x80x9cpass throughxe2x80x9d routing to the new subdomain server.
The routing tables for domains, subdomains, sub-subdomains, etc., are typically implemented as simple text files stored on the disk subsystem of the various servers, such as the disk subsystems (7 and 3) shown in FIG. 1. To promote the easy interchange and exchange of routing definitions, RFC1033 defines standard formats for a record for each domain name and subdomain name, and recommends that these be stored in flat text files on each domain server""s disk subsystem. These records are referred to as xe2x80x9cresource recordsxe2x80x9d, or xe2x80x9cRRxe2x80x9d for short. Special records, referred to as xe2x80x9cglue recordsxe2x80x9d, serve as pointers to other name servers which can fully resolve, or translate, a domain-subdomain address to a numeric IP address. These records on each name server define different xe2x80x9czonesxe2x80x9d, which are subtrees of the address range or tree which the domain name server serves. These are particularly well defined in RFC1034 and RFC1035.
In operation, the address scheme is simple but time consuming. A network administrator, or xe2x80x9cwebmasterxe2x80x9d, is responsible for the manual configuration and maintenance of these records. At first glance, the task to create a new subdomain sounds simple, and is eloquently described as the following three steps on page 11 of RFC1033 Domain Operations Guide:
(1) Setup the new domain server and/or the new zone file,
(2) Add a Name Server record for each server of the new domain to the zone file of the parent domain, and
(3) Add any necessary glue Resource Records.
In reality, this may involve accessing physically or remotely the file systems of several servers, including log-on and password procedures. To be done correctly, some form of traffic engineering should be done to estimate the impact of adding a particular subdomain to the current name server with respect to the additional traffic or number of xe2x80x9chitsxe2x80x9d it will receive. The architecture implemented by the definitions and combinations of the domains and subdomains on specific server machines ultimately defines the performance and responsiveness of the network. Thus, not only do network administrators create new resource records when creating a new subdomain, but they also must continuously modify these records to optimize for ever-changing traffic patterns. A further drawback of the prior art process is that the creation of real subdomains has to be recognized and propagated by DNS servers throughout the Internet, a process that can take from 1 day to 2 weeks including administrative delays and 18 to 24 hours network propagation delay.
For these reasons, management and administration of subdomain names is quite time consuming in reality even though subdomains are an attractive option in various situations. So, while the addressing scheme is attractive from the user-interface perspective, it can be quite unattractive to the network planners due to the labor-intensive nature of operating the service.
Further, not all subdomain servers require dedicated and static IP addresses associated with their host names. Often, it is desirable to quickly create a sub-domain under the upper-level host domain name hierarchy so that different content can be published on the web which is more relevant to the subdomain name. An example would be xe2x80x9cauctions.domain.comxe2x80x9d to redirect the user to the xe2x80x9cauctionsxe2x80x9d page under a more popular website called xe2x80x9cwww.domain.comxe2x80x9d. Similarly other areas may also need special and direct attention, such as xe2x80x9cshopping.domain.comxe2x80x9d.
Therefore, there exists a need in the art for a system to quickly and efficiently create and manage subdomain names without extensive webmaster intervention. There is a need in the art for this system to be realizable on standard hardware and software platforms use for World-wide Web home page and domain name servers. Further, there is a need in the art for this new system and method to allow the virtual subdomains to be remotely located from the actual subdomain name server itself to enable the distribution of network server hardware resources and bandwidth demands.
The present invention modifies an existing domain name server platform in order to have it intercept all web browser queries to a higher level IP address, such as 157.6.7.xx, where xe2x80x9cxxxe2x80x9d is any value in the range of 1-254, or to any URL which is translated to fall within this IP address range. If the requested IP address or domain name is not recognized by the standard domain name server and the standard DNS database, a server script is launched to dynamically resolve the unknown address rather than returning a standard xe2x80x9cError 404: File Not Foundxe2x80x9d message to the requesting web browser. The script accesses a database of virtual subdomain names which are mapped in the database to actual subdirectories on the same or a remote server. For example, if a query to http://www.virtualsubdomain.domain.com is received, and virtualsubdomain.domain.com is not recognized as a registered domain name by the standard DNS server, the script will resolve it and map it to http://www.domain.com/subdomain, or any other file on a web server which is actually registered. Using this method, the creation of a virtual subdomain requires only the steps necessary to create a subdirectory. This enables it to be performed rapidly if handled manually, or it can be created automatically by any network client with privileges to create subdirectories on the web server in question.